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This paper examines four primary methods of working across disciplines during R&D and early 
design of large-scale complex engineered systems such as aerospace systems. A conceptualized 
framework, called the Combining System Elements framework, is presented to delineate several 
aspects of cross-discipline and system integration practice. The framework is derived from a 
theoretical and empirical analysis of current work practices in actual operational settings and is 
informed by theories from organization science and engineering. The explanatory framework 
may be used by teams to clarify assumptions and associated work practices, which may reduce 
ambiguity in understanding diverse approaches to early systems research, development and 
design. The framework also highlights that very different engineering results may be obtained 
depending on work practices, even when the goals for the engineered system are the same. 


1 INTRODUCTION 

Fundamental to researching and designing engineered systems is system integration and working 
across technical disciplines. Engineering integration spawns significant polarities: failures and 
innovation, system fragility and system enhancement, team confusion and new insight, organizational 
turf battles and lasting amity. This research seeks to improve work practices at system integration 
points and ultimately improve system design by providing a detailed understanding of work practices 
at the earliest stage of integration - during research and development (R&D) and early design. We 
focus specifically on early stage cross-disciplinary, human-to-human interactive work practices of 
groups working on Large-Scale Complex Engineered Systems (LaCES) such as aircraft and 
submarines where hundreds or thousands of engineers and scientists are engaged from large, dispersed 
organizations. While there is extensive literature on examining cross-disciplinary practice in a variety 
of settings (e.g., academia, small businesses) for an array of different purposes (e.g., learning, product 
design), the literature on cross-disciplinary practice for LaCES is focused on Multidisciplinary Design 
Optimization (MDO) and toward the later stages of development such as systems engineering. 1 11 

In this research we sought not to make common assumptions on the approach engineers take toward 
working across disciplines in developing LaCES such as assuming: the integration followed a 
prescribed hierarchical path; the integration focused on connecting mathematical models and 
hardware; or that MDO or organizational leaders would address much of the needs of early cross- 
discipline work. Rather, we contribute to the literature via a theoretical and extensive empirical 
analysis examining current work practices in actual operational settings where LaCES are researched 
and designed, allowing the findings to emerge from real work practices. We asked: What are current 
practices and perspectives on interdisciplinary interactions during R&D and early conceptual design of 
LaCES and why might these prevail and persist? 12 
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In this paper we summarize our findings on the four most common methods of interacting across 
disciplines and we derive an explanatory framework hereafter called the Combining Systems Elements 
(CSE) framework. Teams and organizations may use the framework to improve clarity regarding 
many aspects of the research and early system integration and design process. As mentioned, the 
context for this study was large, dispersed organizations creating very large, complex engineered 
systems. While the findings are not generalizable, they are transferrable to many contexts where 
multiple elements are being combined to create an engineered system. This paper begins with 
background on the framework and how best to use it, followed by an overview of the research 
methodology. The remainder of the document is dedicated to a detailed description of the framework. 
The synthesized findings include several examples from the empirical data obtained. 

2 BACKGROUND AND USE OF THE COMBINING SYSTEM ELEMENTS 
FRAMEWORK 

Several aspects of the CSE framework are presented in this section to enable the best interpretation of 
the data and most effective use of the framework. The framework was derived from a theoretical and 
empirical analysis of the data obtained and is not exhaustive. The CSE framework is descriptive rather 
than prescriptive: providing deep descriptions of the related engineering and organizational practices 
to enable a clearer understanding of work practices. As an explanatory, sensemaking framework it 
does not suggest best practice but rather clarifies existing practice; hence, the framework describes 
practices and perspectives that overlap as well as interact. The different categories of combining 
system elements are presented separately and contrasted for analytic clarity and convenience rather 
than as an ontological separation. The concurrent nature of the practices should be continually borne 
in mind. The findings represent the most predominant constructs that emerged from the data gathered 
and are not exhaustive of all work practices. 

The constructs are delineated as Connection, Coordination, Collaboration, and Collective. The 
following terminology is used in the discussion: System refers to the focus of the integration effort 
whether it is at a macro level (an aircraft), or at a micro level (a technology), or something less 
tangible (a network). Element refers to what is being integrated into the system whether it is physical 
hardware (wings, metal beams), or software (mathematical models, computer programs), or the (less 
tangible) capabilities an individual brings to a cross-discipline team such as disciplinary knowledge, 
expertise, ideas, creativity, training, and culture. In all cases, the aforementioned different types of 
elements represent aspects that may be combined into a system. 

The CSE framework may be used in a variety of different respects though predominantly it can 
improve clarity and reduce confusion, the latter being a common complaint of the respondents in this 
work. The variable and equivocal nature of cross-discipline work can create confusion via 
misunderstandings and misinterpretations 1 ' 3 ' 13 resulting in inefficiencies and potential errors in the 
R&D and design of the system, ultimately impacting final system performance. Further, though 
system integration and team cross-disciplinary interactions are very common in developing large 
systems in engineering, there is considerable equivocality and variation in terminology, leadership, 
information sharing, risk, creativity, system and organizational constraints, etc. As a platform for team 
discussion, the framework can aid in communicating expectations and delineating organizational 
practices. Similarly, as a sensemaking tool, it may help organizations and teams make sense of their 
existing processes and potential outcomes. 

3 RESEARCH METHODOLOGY 

An interdisciplinary perspective informed by engineering practice and theories from organization 
science and psychology was adopted in the research. We examined the interdependence of the 
engineering disciplines and the associated non-hierarchical interactive practices between researchers 
focusing on human-to-human interactions rather than between mathematical models as in traditional 
Multi-Disciplinary Optimization (MDO). The research design consisted of a three-fold, integrative 
approach that combined survey, interview, and ethnographic research using a descriptive analysis 
approach that “attempts to understand cognitive work practices from the perspective of the subject, in 
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the contexts where the subjects find meaning” rather than in a simulated research laboratory 
environment. 14 The three different research methods were used to help examine different facets of the 
problem domain. However, the ultimate approach for this study was synthesis of the different data to 
enable an integrated, rigorous, and comprehensive analysis. A detailed description of the research 
methodology is provided in references 12 and 15. 

The multi-method approach chosen used three methods. 

1) Open-ended surveys to identify current perspectives 16 on interdisciplinary interactions by sampling 
a diverse group of 62 leaders that spanned industry, government, and academia. They provided a 
unique assessment of current thinking and took place prior to the interviews, which also guided our 
interview design and analysis. The survey focused on obtaining short, written answers to seven open- 
ended questions such as: “ Please describe things that encourage interdisciplinary interactions ” and 
"Please describe the obstacles to interdisciplinary interaction. ” 

2) Semi-structured interviews to provide detailed, concrete examples of practices. The interview data 
allowed us to obtain detailed, concrete examples of cross-disciplinary practices through the purposeful 
participant recruitment of 20 practitioners with diverse experiences and responsibilities in aerospace 
R&D and conceptual design. The 20 respondents were carefully chosen to provide a balanced sample 
considering years of experience, job site locations, leadership and staff positions, and diversity of 
engineering tasks. The interviews offered comparative data “for understanding the world from the 
view of those studied” and helped to “unfold the meaning of their experiences.” 17 ’ 18 Example 
questions asked during these interviews included: “I’m interested in hearing about an experience you 
had in working with someone outside of (their home area of work). Tell me about it. ” "Can you 
describe what challenges you faced?” “I’d like to hear about what you gained from the experience?” 

3) Insider ethnography to provide a rich, descriptive account of cultural and organizational work life. 19 ' 
25 Ethnographic research for this study was primarily conducted in aerospace R&D settings via 20 
years of insider involvement and extensive interaction with a wide variety of aerospace R&D and 
design entities. The long duration of the insider ethnography provided critical insight to discern “the 
more subtle, implicit underlying assumptions that are not often readily accessible through observation 
or interview methods alone.” 20 

3.1 Integrative Data Analysis Approach: From Codes to Synthesized Analysis 

Data analysis was interpretive involving qualitative content analysis using theoretical sampling and 
methods of constant comparison (in keeping with the grounded theory methodology developed by 
Glaser and Straus). 26 Data analysis was also inductive, guided by constant comparison methods, in 
which themes were identified, continuously compared to newly emergent themes, and revised based 
on the comparison. 26 Data from all research methods were integrated and re-coded as new findings 
emerged and the research design was adjusted accordingly. 27 While a highly inductive data analysis 
approach guided the findings, to prevent assiduous theory avoidance, this work has theoretical 
underpinnings in several genres of literature including organizational science, cross-disciplinary 
studies, psychology, and complex systems. 18 ’ 28 ' 37 

The three research methods were integrated into an analytical approach that included first-order 
analysis of data from each method by itself followed by second-order analysis that integrated data and 
provisional findings from multiple methods to create updated findings. Then, a comprehensive 
synthesis incorporated relevant theories and created theoretical conceptualizations grounded in the 
empirical data and backed with theory. The synthesized analysis of the study data was driven by 
exploring patterns, processes, and relationships and sought to illuminate the actual engineering and 
scientific practices and perspectives on interdisciplinary interactions. Except where noted, the findings 
herein are a second-order synthesis of all of the codes, themes, and meta-themes from all data. 
Triangulation was an essential aspect of the research design. 

To echo what is well documented in qualitative research theory literature, we note that a quantitative 
frame for analysis of the data is an inappropriate frame given the sample size and research 
methodology used. Accordingly, statistical generalizability is not the aim for this study but rather 
generalizability in the context of R&D in LaCES is the appropriate frame for considering potential 
transferability of these findings to other contexts. 
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3.2 Synthesized Findings from all Three Methods 

As noted earlier, data from all three research methods were integrated to create the synthesized 
findings presented below. The unit of analysis of this study is a group level of analysis. Though 
specific individuals served as respondents for the survey and interview portion of this research (62 
from the open-ended surveys and 20 for the semi-structured interviews), their data were integrated 
with scores of respondents who provided input for the ethnographic portion of this research. The 
synthesized findings represent a triangulated analysis based on input from all sources of data. 

4 DIFFERENTIATING CROSS-DISCIPLINE PRACTICE 

Figure 1 provides as a graphical depiction of the four methods. A description of each method follows 
with an overview of the method, followed by examples and then a brief discussion of each. 



Figure 1 Graphical Depiction of the Combining 
System Elements Framework 


4.1 Connecting 

Connecting is a multidisciplinary effort to join separately developed elements and their respective 
individual disciplines. In this scenario, the researchers that develop the different elements work largely 
independent from one another until the last stages of their research. This effort is multidisciplinary in 
the sense that information between the different elements is exchanged yet individual disciplinary 
methods and theoretical concepts are not questioned or modified but rather updated with additional 
information such as operating or boundary conditions. 3 The elements of the system are largely 
modular. The researchers do not interact significantly during R&D and early design though they may 
provide R&D results and other information to a lead integrator separately with little detailed 
awareness of or knowledge integration with other disciplines. 

Example systems that primarily consist of connecting elements are computer assembly; updating 
existing systems with new technologies; substituting different technologies in a baseline system model 
to determine the change in the system’s performance; and, more conceptually, a jigsaw puzzle or 
mosaic. One team leader with 25 years experience described a connected system as a “patchwork 
quilt. ” Another team leader with similar experience described a weak connection between disciplines 
as: “I don ’t see there being any connection between — a lot of the disciplines don ’t have much 
connection between themselves, ...the [A] group doesn’t really have to work with the [B] and [C] 
group or the [D] group, except for maybe saying, ‘Okay, here’s the boundary conditions of the [end] 
of my [element] to go into the [their element], ’ They don ’t have to do much interaction. ” As portrayed 
in this quote, the researchers in a connected system exchange information creating a multidisciplinary 
system but they do not conduct R&D interactively nor integrate their knowledge and adjust their 
understandings, methodologies, or theories in an interdisciplinary sense. 

Connecting offers the least social and organizational effort since the elements need not interact until 
near the very end of their development. Thus, what may be considered as “program management 
overhead costs” may be small. Perceived (but not necessarily actual) system development risk is lower 
since the elements are known and defined. Traditional stepwise program management processes are 
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easier to implement, as the elements and the system are known or are well defined. However, the 
lower cost and lower risk perception must be compared with a significantly decreased opportunity for 
creativity as compared with the other methods. Many who worked in a connected manner described 
more turf battles and myopic thinking than resulted from the other methods of interacting. 

4.2 Coordinating 

In Coordinated systems the elements are users of a networked system, such as a transportation system 
or Wi-Fi system or a power bus. Elements may or may not interact yet the developers and operators of 
the coordinated system must work interactively with the different elements to clarify user needs and 
changes. In many cases, the performance of a coordinated system may be improved if the users 
(elements) work together, however, this is not always an option. Hence, there is more of a 
multidisciplinary effort between the elements; however, the system developers’ efforts are highly 
interdisciplinary and, depending on the creativity of the developers, their efforts may be trans- 
disciplinary. 

Examples of systems primarily using efforts of coordinating are: hardware, software, testing 
platforms, etc., that are shared by many users; a laboratory or field center where many similar or 
disparate engineers work; or, more conceptually, a family vacation. Some project or team leaders or 
line managers oversee their project, team or line in a coordinated sense by managing several different 
tasks that all share a common topic area and resources (computers, offices, office staff, funding 
source) but the tasks are being conducted largely independently. One researcher who specializes in 
multidisciplinary optimization replied that: “we do integrate from different disciplines into our model, 
but we do not require them to integrate. ’’ 

Further, a system that has been developed via coordination is best considered to be “current” more so 
than “completed” as the system is often continuously being updated or transformed as users and user 
needs change. The development process is thus less stepwise and defined. Here, success of the system 
may not be the system’s ability to address the current needs, but instead, success may be best 
measured as the system’s adaptability to address changing needs, the latter being more challenging to 
quantitatively measure a priori and requiring larger upfront costs. For management, the constantly 
evolving, higher upfront costs for developing more adaptable systems, and the unknowable future state 
of a coordinated system create challenges in some traditional processes that are better suited for 
systems with known system states. 

4.3 Collaborating 

The interactive merger of different concepts and ideas creates collaborated systems. Here teams work 
together to adjust partially-developed elements to enable the elements to work cohesively together. 
The elements are much less modular and much more interdependent than in a connected system. 

An example collaborated system is a physically-integrated system that contains two distinct but 
interwoven sub-systems such as a landing gear and a wing where the landing gear folds inside the 
wing. In this scenario, the R&D and early design teams for the landing gear and the wing may work 
separately for a portion of the development period (multidisciplinary effort) but the sub-system 
interdependence requires interactive work practices (interdisciplinary effort) much earlier than for a 
connected system. Another example of a collaborated system is merging and changing the capabilities 
of two software packages to create a new integrated software package with enhanced capabilities. 
Conceptually, a collaborated system may be envisioned as a tapestry or a composite. 

For example, describing the start of a collaborative effort, a line manager with 25 years experience 
replies: “Group A you’re working on this, group B you’re working on this. We’re starting to see from 
the system studies and everything else, it seems like we could actually get the [system performance] 
that we ’re looking for if we kind of integrate the technologies that you all are bringing your respective 
technologies to the table together, and look at something, an integrated approach rather than just two 
separate approaches. ” 

Collaborating presents greater social and organizational challenges than connecting and coordinating 
and is best understood as the work of an Integrated Product Team (IPT). Logistically, as teams become 


ICED 15 



larger and geographic dispersion grows, the organizational overhead of enabling collaboration can 
become significant. The system design is not as constrained by contributing elements as in the 
connected system; however, this also means that defining a detailed system design requires more time. 

4.4 Collective 

The work of a collective is a highly concentrated collaboration where interaction among engineers 
begins early in R&D and design and team members may co-locate for extended periods to facilitate 
the needed interactions. Collective interdisciplinary interactions involve different disciplines striving 
to achieve a common goal (a new system or innovation) not by focusing on integrating existing 
technologies as is more common in connecting and collaborating, but by proactively exploiting and 
fusing diversity of thought that is resident in the team members. The resulting co-creation of 
knowledge further enhances the diversity of thought as team members re-think their incoming 
assumptions. Collective efforts are inherently interdisciplinary and often trans-disciplinary - the 
resulting need for significant face-to-face time makes collective action challenging for highly 
dispersed teams. In a sense, collective R&D and early design is designing while researching and 
developing. The knowledge and experience generated from single disciplinary research and other 
experiences are the elements integrated into the system more so than existing hardware and software. 
Conceptually, collective action may be envisioned as creating a homogeneous alloy that gains from the 
various capabilities of different metals. 

An experienced team leader from a single discipline group who is responsible for a highly cross- 
disciplinary team describes the benefits of working collectively : “So, you got the ‘gotta-haves ’ and the 
‘want-to-haves ’ and the ‘it-would-be-nice-but’ . Oftentimes, if you don’t understand the system you 
don ’t understand the something that may be on that ‘it-would-be-nice-but’ can cause a revolutionary 
change if you can make one of those ‘it-would-be-nice-buts ’ into a ‘gotta-have’. ... They didn’t know 
that we could [do] things [in] other ways. Nobody had asked them, ‘What if you could [do] this some 
other way? How would you do it? ’ They said, ‘Never been asked that. ’ So, then they started looking 
under these rocks and all of a sudden they’re going: ‘Oh my gosh! There’s this whole field that we 
found that’s never been plowed that has some rich possibilities, very great capabilities. ’ ...[Meetings 
are] much more dynamic. There’s a lot more interrelationships, a lot more talking back and forth and 
the different people in the room that are representing different disciplines are asking questions. ” 

Cross-disciplinary interactions that are collective in nature require the most interaction between 
disciplines. A diversity of literature addresses the theoretical basis of collective constructs and inspired 
the use of the term here. 38 ' 43 One exemplar that provides insights on collective interactions across 
disciplines is Weick’s research on “collective mind” in sensemaking theory, which describes some of 
the aspects of “interrelating” that are essential for developing a system collectively. 4142 The research 
on collective mind considers the cognitive processes of a group that must heedfully work together to 
achieve a solution. It is also important to note that collective mind (in collective interdisciplinary 
teams) can occur in underdeveloped groups provided the interrelations between group members are 
done heedfully. Heedful interactions may be described as: are more or less purposeful, attentive, “tied 
together by trust,” and are interactions where mutual respect is valued over agreement, diversity of 
thought and experience are embraced while coordination of action is emphasized. 41 In collective mind, 
teams focus on “interrelating their know-how” which improves comprehension of a system. 41 
Madhavan and Grover also highlight the opportunities for knowledge creation: “frequent interaction 
among team members can contribute to the building of strong ties between them (Krackhardt 1992), 
which further facilitates the use and creation of knowledge within the team.” 43 Much of the knowledge 
is held tacitly or collectively, making interpersonal relations more important while simultaneously 
making explicitly sharing information more difficult. 

All of the conceptualizations above ( connection , coordination, collaboration, and collective) may 
embody some aspects of collective mind; however, the inconsistency and less mindful nature of 
interrelations in connection and coordination efforts reduce the opportunities for collective action 
considerably, for collective mind is built on a well-developed mutually shared field of the heedful 
interrelating which is tightly coupled, but the tight coupling is social rather than technical - though 
most engineers focus more on the latter. 41 
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5 DISCUSSION 


Table 1 provides a comparative summary of the salient characteristics of the four methods. In all 
cases, the capability of the final system often transcends the sum total of the original elements/inputs. 
The different methods highlight several important aspects of early system development. Most 
importantly, the engineered system resulting from the different methods may be quite different even 
though the design goal and associated system requirements are the same. The system is ultimately a 
function of its desired performance characteristics as well as the manner in which it is developed. 12 
Hence, differences in the organizational, social, and cognitive aspects can lead to unplanned variations 
in the engineered system. These differences include proximity of the work group; the nature of social 
connections in the organization; cognitive challenges placed on the participants; and differing 
unspoken assumptions regarding integration. Though infrequently clarified early in team formulation, 
these assumptions influence the mental models and work practices of the dispersed teams. 

For example, each of the methods has differences in engineering aspects such as: expectations about 
the inclusion of previously developed engineering concepts (which also may have career implications 
for participants); level of specificity needed upfront regarding the final system; and the frequency and 
depth of team interactions. These differences were often not clarified in practice, as most respondents 
to this study were not fully cognizant of the differences themselves. Nearly all respondents appeared to 
have clarity on the engineering goal of their interactions with other disciplines yet lacked clarity on the 
different methods by which to do so and were not clear which method was expected of them. Most 
respondents expressed some frustration as they described their efforts in trying to accomplish one 
method of interacting while others with whom they were interacting had different expectations. 
Further, despite the different needs and constraints of each method, some upper management 
evaluated the output of each of these four methods with the same lens. For example both collaborative 
and collective efforts become greatly strained as teams become larger and more dispersed. 
Correspondingly, regardless of the goal, respondents tended toward more connected or coordinated 
action as team size grew or as team members became more geographically dispersed. 

Commonly used system integration terminology is also a source of equivocality in combining system 
elements and creates confusion in the organization. For example, the terms interface, interaction, 
interdependency, and decomposition are used extensively in describing the relationships between 
elements in an engineered system. While the academic definitions of these and other system 
integration terms were clear to nearly all the respondents, the variations in their approach were not 
clear among most in the organization and the resulting variations in assumptions and perspectives have 
widespread impacts on engineering practice. 

One example is the term interface. Literally meaning “the common boundary between two bodies,” 44 
the term interface is used to describe the place of connection between two or more elements in a 
system. Interface specifics have been used for decades as a way of communicating system integration 
details; as such they provide a common way for engineers and scientists to make sense of an integrated 
system. For highly modular systems, interfaces are appropriate, and modularity is an essential element 
in the design of many systems. 45 However, clear interfaces between some system elements (and hence 
disciplines) do not exist for some large engineered systems. Further, attempts to create clear interfaces 
to simplify practice may result in setting up the R&D and early design effort in a manner that does not 
lead to the integrated system performance desired. 

For example, interfaces are most critical in a system integrated by connection because the system may 
be described as a combination of modular elements. Interface has less meaning in a system integrated 
by collaboration because the elements were designed to integrate more cohesively and distinct 
interfaces begin to blur. To an even greater extent, the term interface may have little meaning in a 
system integrated by a collective, as boundaries between elements can be abstruse. The term interface 
has many meanings in a coordinated system as elements of the system may or may not interact yet 
they share a common system. And, the ambiguous nature of interfaces in a coordinated system, such 
as a transportation system, makes interface documentation, required in some organizations, a less 
useful process. 
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Table 1. Comparative Summary of Principal Characteristics of the Methods in the 
Combining System Elements Framework (Source: A. R. McGowan) 



Connecting 

Coordinating 

Collaborating 

Collective 

Synopsis 

Connecting separately 
developed elements into a 
system 

Integrating user needs to 
create a common or shared 
artifact. This multi-user 
artifact is the system. 

Creating a heterogeneous 
combination using aspects 
of different elements 

Creating a homogeneous 
mixture or solution from 
different elements. 

System 

description 

System is a combination of 
different joined elements 

System is dynamic and 
evolves as elements (user 
needs) change. 

System is a combination of 
different integrated 
elements. The original 
elements have been partially 
modified during the 
integration. 

System is a collective (or 
somewhat of a fusion) of 
diverse elements. 

Element 

description 

Elements used to develop 
the system are generally 
tangible articles or 
components of physical or 
cyber hardware, software, 
mathematical models, etc. 

Elements of the system are 
diverse user needs. 

Elements used to develop 
the system may be physical 
or cyber objects, as well as 
personal experience, 
knowledge bases, etc. 

Elements used to develop 
the system include a wide 
diversity of constructs, from 
tangible hardware to 
personal experience, 
knowledge, and culture. 

Nature of the 
combination 
of elements 

Individual elements are 
physically connected but 
distinct, with little (relative 
to element size) 
modification to facilitate 
connection. 

Elements of the system 
(user needs) are inherently 
dynamic and sometimes 
irrational. User needs 
(elements) may or may not 
be altered due to interaction 
with the system. 

Individual elements are 
partially merged and/or 
physically integrated to 
create the overall system or 
solution, yet the individual 
elements remain somewhat 
distinct in the system. 

Individual elements are 
fused together, becoming 
irreducibly intertwined to 
create a new system where 
the original individual 
elements may or may not be 
distinctly apparent in the 
created homogeneous 
system. Contributions of the 
individual elements to the 
system are not necessarily 
clearly separable after 
forming the collective. 

Integration 

summary 

Task of joining and 
assembly. 

Task of organizing, 
negotiating, and sharing 
information and resources. 

Task of converging aspects 
of different elements 
(concepts, knowledge bases, 
etc.) to arrive at an 
integrated solution. 

Task of co-creating a new 
capability or knowledge 
bases, etc. by drawing upon 
different knowledge bases 
(expertise, or capability, 
etc.) in order to conceive of 
a new system or to address a 
problem. The new system 
(or problem solution) is a 
homogeneous collective of 
a diversity of 
elements/inputs (the 
diversity of which was 
essential). 

Primary 
focus during 
integration 

Attention directed to the 
interface where the 
elements connect, and 
toward the interactions at 
the interface. 

Attention directed to 
clarifying user preferences 
and negotiating a common 
ground between users. 

Attention directed to 
interactions between 
elements in the integrated 
solution. The concept of 
“the interface” between 
elements loses significance 
as the integrated solution 
requires iteration and some 
modification of the 
elements. 

Attention directed toward 
incorporating, fusing, and 
embodying different 
wisdom, inspiration, tacit 
knowledge, assumptions, 
experience, etc. 

Nature of the 
interaction of 
the 

researchers, 
developers, or 
designers. 

During R&D and early 
design of the elements, 
infrequent interaction 
between element 
researchers, developers, and 
designers generally occurs 
and is likely not needed. 
Technology maturation of 
each element occurs 
primarily within a domain 
area. Significant interaction 
is required for connecting 
the elements after they 
reach a specified state of 
maturity. Interaction is 
mostly convergent in nature. 

Elements of the system may 
or may not interact. 
However, the system 
researchers and developers 
interact continuously with 
elements beginning early in 
R&D and early design. 
While the users may or may 
not physically connect or 
interact, the system 
developer interacts with 
different users of the 
system. Interaction between 
system and elements is 
convergent and divergent 
and interactions must begin 
at a very early stage in 
system development. 

A greater level of tacit 
knowledge sharing is 
generally required 
compared to connecting, 
thus participants that ‘own’ 
the different elements of the 
system must interact in 
physical proximity for some 
portions of system 
development. Interaction 
between disciplines is very 
high once the elements 
reach a specified state of 
maturity. However, as the 
integration is a merger of 
different elements, requiring 
potentially significant 
changes to each element, 
interactions begin earlier in 
R&D and design than for a 
connected system. 
Interactions between 
disciplines are mostly 
convergent with occasional 
divergent discussions. 

Highly divergent and 
convergent interactions. 
Divergent as the team 
interacts to create aspects of 
a new system. Convergent 
as they determine how to 
develop the final system. 
Emergence of a new system 
(or solution to a problem) 
with new capabilities, not 
previously envisioned, often 
occurs. Interactions require 
working together frequently 
with the highest levels of 
tacit knowledge sharing. 
Interactions between 
disciplines begin early in 
R&D and design. 

Cross 

Disciplinarity 

More of a multidisciplinary 
effort 

More of a multidisciplinary 
effort between the elements; 
however, the system 
developer’s effort is highly 
interdisciplinary and, 
depending on individual 
creativity and opportunity, it 
may be trans-disciplinary. 

Collaboration typically 
begins with a 

multidisciplinary effort but 
often ends with an 
interdisciplinary effort. 

Inherently interdisciplinary 
with frequent trans- 
disciplinary results 
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6 SUMMARY 


This research focused on conducting a theoretical and empirical analysis of current work practices in 
actual operational settings at the earliest stages of system integration (R&D and early design) for very 
large engineered systems such as aircraft. For systems of this size and complexity, comprehensive 
knowledge of the system is dispersed among specialists whose expertise is often in one system 
component or discipline. The variety of methods and equivocality of terminology in combining 
elements to create a system often create confusion on engineering teams. A sensemaking, explanatory 
framework was derived that may aid engineering teams in clarifying their integration and cross 
discipline assumptions and processes. The Combining Systems Elements framework was presented as 
a means of delineating several constructs of working across different disciplines in R&D and early 
design of large engineered systems. The four methods of combining system elements were 
conceptualized as Connection, Coordination, Collaboration, and Collective. In all cases, the practices 
and perspectives are distinct but not fully separable, for they overlap and interact. Contrastive analyses 
were used to enhance clarity with the expectation that understanding of existing practices can offer a 
foundation for future improvements to design practice. An important finding is that each method may 
produce significant differences in the final engineered system even when the original system 
requirements or objectives are the same. 
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